Search results

In September 1990, the U.S. Department of Education's Library Technology and Cooperation Grants Program awarded a three‐year grant to the Florida Center for Library Automation (FCLA), an agency of the Florida State University System, to develop software adhering to the ANSI Z39.50 Information Retrieval protocol standard. The Z39.50 software was to operate over the Open Systems Interconnect (OSI) communications protocols and be integrated with FCLA's NOTIS system, which is shared by all nine state universities in Florida. In order to test the correctness of its Z39.50 software, FCLA sought out other library software developers who would be willing to develop Z39.50 systems of their own. As part of this process, FCLA helped to found the Z39.50 Implementors' Group (ZIG), which has since gone on to improve the standard and promote Z39.50 implementations throughout much of the North American library systems marketplace. Early on in the project, it became apparent that TCP/IP would be a more heavily used communications vehicle for Z39.50 messages than OSI. FCLA expanded its design to include TCP/IP and, by the end of the grant in September 1993, will have a working Z39.50 system that can communicate over both OSI and TCP/IP networks.

Chadwyck‐Healey Announces the Patrologla Latina Database. The Patrologia Latina Database is a major text conversion and electronic publishing project. It is a complete machine‐readable edition of the classic nineteenth‐century collection of texts edited by the ecclesiastical publisher Jacques‐Paul Migne.

Monitoring System Performance. This is the final installment of a multipart article on resource usage issues in library automation systems. The first three parts dealt with specifying resource usage and performance goals. This article will deal with monitoring system performance. Most system monitoring in the current library automation world is anecdotal. The person responsible for the system receives a telephone call, or many calls, indicating that the system is not performing properly. Usually, that is the sum total statement of performance. By the time an individual actually becomes frustrated enough to call about the system's degraded performance, their perception of the problem has generally grown far worse that the problem actually is. Yet, in many cases, the perception is what really matters and it is often quite impossible to budge people from that perception once it is formed.

I promised that this month I would demonstrate a Z39.50 connection by emulating the two systems, showing the messages the protocol data units (PDUs) generated by each system. Before doing this, however, I need to digress to discuss syntaxes. In order for two systems to communicate, they not only need to agree on what will be sent but also on how this information will be represented. OSI protocols in general, and Z39.50 in particular, specify information representation by defining a “transfer syntax.” A transfer syntax consists of a humanly representable definition of the information, called the “abstract syntax,” and specification of the rules used to encode the abstract syntax into a format manageable by machines.

This issue, we will discuss another new features planned for Version 3 of Z39.50. The scan service is the sole service defined in the new Browse Facility. Other services should be standardized later. These include the ability to browse through a record in a result set or in a database, and the ability to browse a database itself. Scan provides the ability to browse a list of values, known as a term list, that particular attributes may take in a database of group of databases. A common example of this function is to scan an index created from a database, such as an author index created from a bibliographic database. Non‐library examples would be browsing the names of people in a personnel file or the course numbers in an academic calendar database.

Now that we have an understanding of the operation of a Z39.50 system, the meaning of all of the parameters encapsulated in Z39.50 APDUs and the use of ASN.1 and BER to encode those PDUs, we will attempt to emulate the transfer of PDUs between two conformant systems.

This month's article discusses the query mechanism built into the Z39.50 protocol. There are three types of query defined: type 0, type 1, and type 2. The query is encapsulated in the SearchRequest PDU, discussed last month, and is tagged by its query type value. The type 1 query is an integral part of Z39.50 and is discussed in detail below. Types 0 and 2 are not specific to Z39.50 and are far less important to an understanding of the protocol.

Examines the dilemma of choosing between the computer hardware available due to the ′open system′ concept. States that libraries should adopt the concept of service‐level agreements defining clearly specified and measurable metrics, and the minimum levels of acceptable computing services. Summarizes the recent developments in mainframe architecture, especially the advent of optical storage and the ′hot topic′ of automated operations.

This is the second part of a multipart series on performance issues in library automation, especially as they pertain to the RFP process. In the last issue, I discussed some of the kinds of questions that should be posed by a library considering a new automation system or a significant upgrade to an existing system. These were questions the library needed to answer in order to prepare for developing the part of the RFP that is related to performance concerns. In this issue, I will go through a semi‐fictitious RFP as an example of how it is usually done and what is wrong with that.

Specifying RFP Performance Criteria. Last month, we discussed how not to specify performance criteria in an RFP. This month, we will look at how an RFP section on performance should be developed. This month's column will consist predominantly of worksheets that I have developed to assist in this task. As with any essentially generic tool, these worksheets need customization to fit any particular situation.